I have a few concerns about this PR.

The micros-to-days conversion in spark_to_date uses (micros / 1_000_000 / 86_400) as i32. Integer division in Rust truncates toward zero, which gives wrong results for pre-epoch dates with non-midnight times. For example, a timestamp like "1969-12-31 12:00:00" would produce micros = -43200000000. Dividing by 1_000_000 gives -43200, then dividing by 86400 gives 0 (day 0 = 1970-01-01), when the correct answer is day -1 (1969-12-31). You would need floor division here, something like micros.div_euclid(1_000_000).div_euclid(86_400) as i32.

The spark_to_chrono format converter only handles a small subset of Spark's SimpleDateFormat patterns (yyyy, MM, dd, HH, mm, ss, fractions, XXX, Z). Patterns like M (single-digit month), d (single-digit day), yy (2-digit year), a (AM/PM), or E (day of week) would pass through unconverted and silently produce wrong results. It might be worth either validating that the format string only contains supported tokens and falling back to Spark for unsupported ones, or documenting the supported subset in getSupportLevel.

Speaking of getSupportLevel, CometParseToDate doesn't override it, so it defaults to Compatible(). It probably needs similar type checks to CometGetTimestamp for TimestampNTZType and other unsupported input types.